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RUNWAY SAFETY MONITOR 
Algorithm for Single and Crossing Runway 
Incursion Detection and Alerting 

1.0 INTRODUCTION 

The Runway Safety Monitor (RSM) was developed by Lockheed Martin in support of 
NASA’s Runway Incursion Prevention System (RIPS) research. This work was conducted 
under the NASA Aviation Safety and Security Program’s Synthetic Vision System project. 
The National Transportation Safety Board (NTSB) has, for a number of years, listed 
runway incursions on its most wanted list of transportation safety improvements in 
aviation. The NTSB has made a recommendation to stop runway incurs ions/ground 
collisions of aircraft and give immediate warnings of these events directly to flight crews in 
the cockpit [1], The NTSB recommendation is consistent with the goal of NASA RIPS 
research to investigate technology and generate requirements for an aircraft based system 
than can eliminate runway incursions. 

RSM is an important step in realizing the NASA RIPS research goal. The RSM algorithm 
is a software package that runs on the aircraft to detect hazardous situations that cause 
runway incursions as early as possible and alert the flight crew in time to take necessary 
corrective or evasive action. RSM is a component of the overall RIPS research software 
that also includes advanced data communications, real-time graphics displays and aural 
warnings to provide pilots with enhanced situational awareness. The possibility of runway 
incursions is greatly reduced by RIPS software capabilities and displays including an 
electronic moving map (EMM) display, a heads up display (HUD), a primary flight display 
(PFD), cockpit display of traffic information (CDTI), taxi routing, air traffic control (ATC) 
instructions, aural alerts for off taxi route and crossing hold, and other features that increase 
the pilot’s situational awareness. Results of flight testing verify that incursions are less 
likely to occur when these RIPS capabilities are employed on aircraft. However, in the 
event an incursion is in progress or about to occur, incursion detection and aural/graphical 
alerting by RSM on board the aircraft allows evasive or corrective action to be taken 
immediately to reduce or eliminate the possibility of a serious accident. 

The Federal Aviation Administration (FAA) defines a runway incursion as “any occurrence 
in the airport runway environment involving an aircraft, vehicle, person, or object on the 
ground, that creates a collision hazard or results in a loss of required separation with an 
aircraft taking off, intending to take off, landing, or intending to land.” [2] The RSM is 
designed to detect and alert for the conditions specified in this definition. However, the 
definition is vague leaving many situations open for interpretation. The upgraded version 
of RSM uses the broader term, “runway conflict”, which encompasses the FAA definition 
of incursion but also includes other situations that could cause a collision hazard. This 
report defines a runway conflict as any occurrence including loss of separation that could 
result in a collision hazard on the runway or during any phase of take off or landing. This 
definition includes situations when both aircraft involved in the conflict are airborne such 
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as on approach to crossing runways or intersecting approach flight paths. Runway conflict 
also includes situations that involve violations of ATC departure and arrival separation 
procedures. RSM is designed to detect and alert the flight crew to these situations. The 
specific runway conflicts detected by RSM are described in more detail in other sections of 
this report. 

RSM was flight tested on NASA’s B-757 research aircraft at the Dallas-Fort Worth 
International Airport (DFW) in October 2000. The description and perfonnance of RSM 
for that flight test was documented in a NASA contractor report [3] and Digital Avionics 
Systems Conference paper [4], During that flight test, RSM was tested successfully for a 
number of single runway incursion scenarios. Single runway incursion scenarios involve 
two aircraft using the same runway or one aircraft landing/taking off with an obstruction on 
the runway. Since the DFW flight test, RSM has been upgraded and enhanced to include 
incursion scenarios for crossing runways and intersecting flight paths as well as additional 
single runway scenarios that were not available for the DFW flight test. Many other new 
features and capabilities have been added, and the algorithm has also been converted to a 
standalone version that runs independently on UNIX and PC systems. The advanced 
version of RSM has been tested in a full mission piloted simulation conducted in March 
2002 [5]. In the summer of 2004 the algorithm was flight tested at the Reno/Tahoe 
International Airport (RNO) and the Wallops Flight Facility (WAL) during the Gulfstream- 
V Integrated Technology Evaluation (GVSITE) flight test. This report supplements and 
updates the previous contractor report for the DFW flight test [3] and describes in detail the 
performance of RSM during the GVSITE flight test at Reno and Wallops. 


2.0 GENERAL DESCRIPTION AND CAPABILITIES 

2.1 Incursion Detection and Alerting 


The RSM is a standalone program designed to run on board an aircraft using data linked 
traffic infonnation. It runs in conjunction with the RIPS software that provides the data 
communications as well as aural alerts and graphics displays needed for incursion alerting. 
RSM does not use detailed terrain or airport databases but does require highly accurate 
information for airport runways, and accurate real-time flight data for ownship and traffic 
on or near the airport. 

RSM detects a runway incursion and issues an alert when the ownship aircraft (e.g., 
Gulfstream-V used for GVSITE) is using a runway and there is a conflict with other traffic 
using the same runway, a crossing runway or an intersecting flight path. Other traffic is 
defined as aircraft, vehicles, equipment or objects that can be identified by one or more 
traffic data sources and data linked to the ownship aircraft. Traffic data sources used for 
GVSITE are described in Section 3.2. 1.1. A conflict, as defined in Section 1.0, is any 
occurrence (including loss of separation) that results in a collision hazard on the runway or 
during any phase of take off or landing. RSM issues a Runway Conflict Alert (RCA) when 
a conflict situation is detected. An RCA is a warning that the potential for a collision exists 
and, therefore, an evasive maneuver should be initiated at the pilot’s discretion. Guidance 


4 



for any specific evasive maneuver is not provided by the algorithm or the alerting system. 
RSM is a single stage alerting system (RCA’s only) and does not issue advisory or 
cautionary alerts before the situation becomes a conflict. An RCA can be triggered due to 
an error on the part of one or both aircraft/traffic involved, controller error, weather or 
other reasons. However, the RSM algorithm does not consider the cause of the conflict 
when issuing alerts. The same alert is issued whether the conflict is the result of action by 
ownship, traffic, air traffic control or any other cause. 


2.2 Runway Incursion Zones 


A major concept of the RSM algorithm is the use of runway incursion zones. A runway 
incursion zone is a software-derived three-dimensional virtual zone that is not depicted on 
flight deck displays. There is one incursion zone for each runway on the airport that 
includes both ends of the runway. The horizontal dimensions of a runway incursion zone 
overlay the associated runway, with the width or sides of the zone extending a constant 
distance from both sides of the runway, and length or ends of the zone extending a constant 
distance from both thresholds of the runway. The zone extends vertically a constant 
altitude above the runway surface. The 3-dimensional incursion zone is the only place 
where flight operations are monitored for runway incursions/conflicts. Figure 1 shows a 
two-dimensional plan view of the runway incursion zones at the Reno airport. Figure 2 
shows the runway incursion zones at Wallops. 

Accurate placement of the incursion zones is critical for correct perfonnance of the 
algorithm and prevention of false alarms. The coordinates for each runway incursion zone 
are computed based on information in the RSM configuration file (see Section 3.1.4) for 
individual runway parameters such as thresholds and widths. The values for the sides and 
ends of the zones can vary for each runway. The sides of a zone are set to be near the hold 
short positions but not too close to set off false alarms if aircraft are stopped with the nose 
over the hold line. The ends of zones vary based on the intersection of the ILS glide slope 
path with the incursion zone altitude. If there is no ILS, a standard glide slope for the 
runway is used. Zones typically extend approximately 2.2 mn from the runway threshold. 
The width of incursion zones is wider at the approach ends than at the runway thresholds 
(see Figures 1 and 2). This difference is due to the allowance of up to a two-dot ILS 
localizer deviation error on approaches. 

When the ownship is using a runway, intentionally or by mistake, the positions of other 
traffic inside the incursion zone for that runway are continually tracked. (See definition of 
other traffic in Section 2.1 above.) In addition, the positions of other traffic inside 
incursion zones that cross the ownship ’s incursion zone are also tracked. Only the runway 
zone used by the ownship and any zones that cross the ownship ’s zone are monitored for 
other traffic. Conflicts between other traffic that do not involve the ownship are not 
detected. Note that when the ownship is not using a runway, traffic is not monitored in any 
runway incursion zone. Also, any possible conflict between the ownship and other traffic 
outside or above the runway zones (such as on taxiways, non-approach areas, etc.) is not 
considered a runway conflict and, therefore, is not monitored by RSM. 
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2.3 Incursion Scenarios 


RSM was designed to detect all possible scenarios for runway incursions/conflicts, 
including conflicts on single runways, crossing runways and intersecting flight paths. This 
is a significant upgrade from the previous DFW flight test where only single runway 
conflicts were detected. Common conflict scenarios on single runways include: ownship 
entering the runway while another aircraft is taking off or landing; ownship landing or 
taking off while another aircraft/vehicle is taxiing across the runway or construction 
equipment is located on the runway; and one aircraft landing while another aircraft is on 
takeoff roll (chase scenario), holding in position for take off, or not yet off the runway from 
a previous landing. Aircraft or vehicles can wander onto a runway by mistake while the 
runway is in use. Another single runway scenario added to RSM is when the ownship is 
taxiing toward a runway with departing or arriving traffic but is either unable to stop or 
does not intend to stop before reaching the hold short line. In this case, RSM may alert 
before reaching the hold line based on a look-ahead or projection capability. 

Typical conflict scenarios on crossing runways are as follows: ownship begins takeoff 
while another aircraft is taking off on a crossing runway (departure/departure) or landing 
on a crossing runway (departure/arrival); and ownship is landing while another aircraft is 
taking off on a crossing runway (arrival/departure) or landing on a crossing runway 
(arrival/arrival). Intersecting flight paths are similar to crossing runways but result in 
different situations that require different incursion detection criteria depending on where 
the flight paths intersect. For example, the intersection can be located before the threshold 
of the arrival runway or beyond the end of the departure runway. There are many different 
scenarios and variations of each scenario if all the possible combinations of conditions are 
considered. 

By definition, an incursion or conflict scenario usually involves the ownship and another 
aircraft, with one or both in the process of taking off or landing, or intending to take off or 
land (see Section 1.0). However, operations when neither aircraft is taking off or landing 
(taxi only operations) can generate possible conflicts if one of the taxiing aircraft is on the 
runway after a rollout, before a takeoff roll or when the runway is used as a taxiway. These 
taxi only scenarios have been added to the RSM’s detection and alerting capabilities using 
strict criteria to prevent false or nuisance alerts. 

During GVSITE, four different scenarios were tested at RNO and seven scenarios were 
tested at WAL, with highly successful results. Fewer scenarios were tested at RNO due to 
airport restrictions. The flight test included some common crossing runway scenarios 
described above as well as some single runway scenarios that were not previously tested 
during the DFW flight test. All scenarios involved a Gulfstream-V (GV) aircraft fully 
equipped with a NASA research system and used as the ownship. A Be200 King Air 
general aviation aircraft and a NASA test van were equipped with ADS-B (Automatic 
Dependent Surveillance - Broadcast) transponders and used as other traffic during the 
RIPS scenarios. The scenarios tested at WAL are shown in Figures 3-9 and the scenarios 
tested at RNO are shown in Figures 10-13. A detailed description and RSM performance 
results for each scenario are described in Section 4.0. 
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3.0 THE RSM ALGORITHM - TECHNICAL APPROACH 


RSM is a standalone software program that receives airport traffic and ownship data as 
input, calculates if the conditions exist for a potential runway conflict, and issues alerts, if 
necessary, for display to the pilot. The algorithm is programmed in the C language and is 
integrated with the RIPS communications and display software through shared memory 
inter-process communications. Although RSM runs as a separate program, it interfaces 
with the RIPS communications software for access to ownship and traffic data, and 
provides alert data to the RIPS display software for aural and graphical display to the pilot. 
The technical approach is described here in sufficient detail to provide an understanding of 
how the algorithm works without going into the low level programming details. A high 
level flow diagram for the algorithm is provided in Figure 14. 


3.1 General Description 

3 . 1. 1 Operational States and Operational State Matrices 

The capability to detect any type of runway conflict is accomplished using a generic 
approach that is based on the concept of operational states and operational state matrices. 
Because there are so many possible conflict scenarios, a generic approach is more effective 
than attempting to identify all the possibilities and program for each case separately (see 
Section 2.3). Seven operational states or flight phases are defined and applicable for both 
ownship and traffic: 

taxi state : aircraft/vehicles taxiing or not moving and stationary objects/equipment. 
pre-takeoff state : ownship positioned for takeoff but before or at the beginning of a 
takeoff roll. (This state is not available for traffic.) 
takeoff roll state : ground takeoff roll in progress, not airborne. 
climbout state : airborne climb out after takeoff roll or after aborted landing. 
landing state : airborne and on final approach. 

rollout state : ground roll out after landing or after an aborted takeoff. 

fly-thru state : flying through/crossing the incursion zone but not landing or taking off. 

The states form a matrix of seven ownship states and six traffic states for a total of 42 
possible state combinations for ownship and traffic. The pre-takeoff state is not available 
for traffic due to lack of data. Each combination of ownship state and traffic state in the 
matrix determines whether or not a conflict is possible for current conditions. If the matrix 
indicates a conflict is possible, additional alerting criteria are applied to determine if a 
conflict alert should be issued. There are actually two operational state matrices used by 
the algorithm, one for single runway conflicts and one for conflicts on crossing runways or 
intersecting flight paths (see Figures 15 and 16). The two state matrices are separate 
because the alerting criteria are very different for single and crossing runways. The 
operational state matrix methodology has proven to be highly effective in both the RIPS 
DFW flight test and the GVSITE flight test. A detailed description of this methodology is 
provided in Sections 3.2.3 and 3.2.4. 
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3.1.2 Software Design 


The overall software design for RSM is straightforward; however, the implementation is 
fairly complex with the addition of crossing runways, intersecting flight paths and other 
capabilities. The algorithm design consists of five components summarized briefly below. 
A detailed breakdown of the design is provided in Section 3.2. 

Component 1 , RSM Main, is the main loop that interfaces with the RIPS shared memory to 
obtain the latest ownship and traffic data, and then calls the algorithm (components 2-5) 
to perfonn runway conflict analysis and testing. When conflict testing is completed, RSM 
Main’s output function writes the conflict alert data to the RIPS shared memory. 

Component 2, Setup and Testing Status, detennines the ownship operational state and 
whether or not runway conflict testing should be started, continued or terminated. If 
conflict testing is not started or continued, the RSM alert data is cleared and the algorithm 
returns to RSM Main without further action; otherwise, testing is initiated by calling 
Component 3. 

Component 3, Conflicts in the Ownship Zone , tests for conflicts in the runway zone being 
used or crossed by ownship. This component finds and tracks all traffic inside the 
ownship zone, and tests for conflicts using the operational state matrix and alerting criteria 
for single runway conflicts. 

Component 4, Conflicts in Crossing Zones, tests for conflicts in other runway incursion 
zones that intersect with the ownship zone. This function is a new capability for RSM that 
was not available at DFW. The software cycles through each zone that crosses the ownship 
zone, finds the traffic and tests for conflicts using the operational state matrix and alerting 
criteria for crossing runways and intersecting flight paths. 

Component 5, Processing Conflict Data, processes the conflict alert data generated by 
components 3 and 4. The processed data are written to a local RSM alert data structure for 
access by the alert data output function in RSM Main (Component 1). If there are no 
conflicts, the alert data structure is cleared. 


3.1.3 Interfacing With RIPS Software 

The live components listed above describe, in general, how RSM performs the critical 
function of runway conflict detection and alerting for NASA RIPS. However, RSM 
utilizes the services of other RIPS software components to propagate the alert data, process 
and format the data, and finally issue the alert information to the pilot aurally and/or 
graphically. The RIPS software contains an important function that checks for alert data 
produced by RSM or any other algorithm, initiates or terminates conflict alert displays and 
aural warnings, and makes the conflict alert messages available for down linking to the 
ground controller. Although not part of RSM per se, the graphics display symbologies and 
aural warnings generated by the RIPS software are an important area of ongoing research in 
human factors to determine the best methodologies for conflict alerting and enhanced 
situational awareness to the flight crew. Example displays that were used during the 
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GVSITE flight test at RNO and WAL are shown in Figure 17a - 17c. These displays show 
alerts for single runway conflicts with ownship landing on approach and traffic taxiing 
across the arrival runway. 

3.1.4 Criteria and Parameters 

Detection of runway conflicts is based on criteria for placement of the runway incursion 
zones, criteria for determining ownship and traffic operational states and alerting criteria 
for single runways and crossing runways/zones. Many of these criteria depend on variables 
that are derived or computed from various sources including the ownship flight 
management system data and traffic data. However, some criteria are based on pre- 
determined constant values and configuration parameters. The program constants are hard 
coded and not changeable. The configuration parameters, contained in RSM configuration 
files read during RSM startup or re-initializations, can be modified. Since parameters can 
vary depending on the airport conditions, ATC requirements and type of aircraft, the use of 
configuration files allow the values to be readily changed without recompiling the software. 
For example, RSM can be configured for different types of ownship aircraft by simply 
changing the ownship configuration file and the conflict alerting parameters can be 
modified based on whether ownship is a large commercial jet, a general aviation aircraft or 
other factors. Many new, configurable parameters have been added to RSM since the DFW 
flight test to refine the algorithm perfonnance and adaptability. 


3.2 Logic and Data Flow 

The logical operations and data flow of the RSM algorithm are described in the following 
sub sections. Refer to Figure 14, RSM Algorithm - High Fevel Flow Diagram. Note that 
in the descriptions below, traffic will often be referred to as targets. Target is a more 
general term that includes aircraft, vehicles, construction objects, runway equipment, etc. 


3.2.1 Component 1: RSM Main 

RSM main is a continuous timed loop whose primary task is to call functions to get current 
traffic and ownship data from the RIPS shared memory interface, call the algorithm to 
perform conflict detection analysis, and write the conflict alert data received from the 
algorithm back to the RIPS shared memory interface. Other functions handled by RSM 
main include startup, shutdown and re-initialization when the airport is changed. Optimal 
timing of the RSM main loop was found to be once per second based on the minimum data 
rate for traffic. More frequent iterations were less effective because many traffic data 
elements were often not updated once per second necessitating data estimation and/or 
interpolation (see Section 3.2. 3. 1.1). 


3.2. 1.1 Traffic Data Function 

RSM main calls the traffic data function to detennine the availability of new traffic data in 
RIPS shared memory and make a local copy for access by the algorithm. During this 
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process, some data elements are converted to different units based on the algorithm 
requirements. Two primary traffic data sources were used during the GVSITE flight test, 
ADS-B (Automatic Dependent Surveillance - Broadcast), and a traffic data fusion system, 
called Multi-Tracking System (MTS), on the Gulfstream-V aircraft. The ADS-B 
transmissions from the BE200 and van were data linked to the Gulfstream. The MTS on 
board the aircraft provided a single fused source from ADS-B, TCAS (Traffic Collision 
Avoidance System), and aircraft radar sources. The fused data and the raw data for ADS- 
B, TCAS and radar were stored in separate areas in the RIPS shared memory. The data 
source, ADS-B or fused, was selected prior to each flight test run. 

3.2. 1.2 Ownship Data Function 

When the traffic function completes the acquisition of new data, RSM main calls the 
ownship function to read the latest aircraft flight management system (FMS) data from 
RIPS shared memory. This data is also copied to a local data structure tailored for use by 
the algorithm and converted to different units, as required. 

3.2. 1.3 Alert Data Output Function 

Upon completion of conflict testing by the algorithm, RSM main copies the conflict alert 
data directly to the RIPS shared memory interface. If there are no conflicts, the data are all 
zeros. After this final step, the whole process reiterates and checking for traffic/ownship 
data updates begins anew. 

3.2.2 Component 2: Setup and Testing Status - Start/Stop/Continue Conflict 
Testing 

If traffic data is available from RSM main, the algorithm has to decide whether to test for 
conflicts or do nothing and return. If not currently testing, Component 2 detennines if 
testing should be started and, if so, what runway incursion zone is in use. If testing is 
already being performed, the algorithm determines if incursion testing should be continued 
or tenninated. The testing status is determined based on the ownship operational state 
described in Section 3.1.1 and the conditions described below. If incursion testing is not 
required or is terminated based on either the ownship state or non availability of traffic 
data, any data previously saved is cleared and the algorithm returns to RSM main without 
further action. It is important to point out that the algorithm starts from scratch each time it 
is called, at least once per second, and assumes there are no conflicts even if a conflict alert 
is currently in progress. For each call, the current data is reanalyzed, testing status and 
operational states are re-determined, and all traffic is retested for conflicts. Any alert in 
progress will be continued or discontinued, or a new alert will be initiated based on the 
most current data and analysis. 


Incursion testing on the ground . If ownship is on the ground, incursion testing is 
initiated if the aircraft is found to be inside of any runway incursion zone and is 
tenninated if ownship exits the zone. The zone may be exited if ownship taxies off 
the runway, takes off and flies outside the zone perimeter or climbs above the 
incursion zone altitude. 
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Incursion testing in the air . If ownship is airborne, incursion testing is started if the 
aircraft is on final and enters the approach end of the runway incursion zone. The 
distance of the approach end of the incursion zone from the runway threshold is 
computed based on the intersection of the ILS glide slope angle, or a default glide 
slope angle in the configuration file, if no ILS, and the incursion zone altitude. For 
GVSITE, this distance varied for each runway but was approximately 13264 feet 
(2.2 nm) from the ends of the runways based on a glide slope angle of 3 degrees and 
an incursion zone altitude of 800 feet. Note: The zone altitude of 400 feet used for 
the DFW flight test resulted in a zone approach end distance of 1 . 1 nm. The higher 
values used for GVSITE were optimal for detection of crossing runway conflicts 
and for early detection of traffic landing on approach. If incursion testing is started 
in the air, it is tenninated when ownship lands and exits the incursion zone, flies 
outside the zone, or aborts the landing by turning and/or climbing above the zone. 


3.2.3 Component 3: Single Runway Conflicts 

If incursion testing is required, this component starts the testing process for conflicts inside 
the runway incursion zone used by the ownship (called the ownship zone). Testing for 
conflicts in the ownship zone uses single runway conflict criteria similar to the criteria 
tested at DFW in 2000. Since then, the single runway criteria have been enhanced to 
improve performance and capabilities. Component 3 performs two main tasks: traffic 
monitoring to find and save data for traffic inside the ownship zone (Section 3.2.3. 1) and 
conflict detection in the ownship zone (Section 3. 2. 3. 2). 

3.2. 3.1 Monitoring Traffic in the Ownship Zone 

This function checks each target in the traffic data list structure populated by RSM main. If 
a target is inside the ownship zone, the data for that target is saved in a separate list for 
ownship zone targets. A maximum of five targets can be saved in the ownship zone list. 
There should rarely be more than five targets in a single runway zone at the same time, but 
this parameter can be changed in the RSM configuration file, if necessary. If a target is no 
longer available or no longer in the ownship incursion zone, its data is cleared from the 
zone list, freeing space for any new targets found in the zone. Zone targets are tracked by a 
unique non-zero numeric ID number or an alpha-numeric flight number if available. If 
neither numeric ID nor flight number is available, the target is labeled as an unknown target 
in the zone. It could be a false target caused by erroneous data, or a valid target that has 
missing IDs. The algorithm tracks only one unknown target because there is no accurate 
way to uniquely identify and store the target data. If there is more than one unknown target 
in the zone, all unknown targets are discarded. 


3.2.3. 1.1 Computing and Smoothing Traffic Data 

The data reported for each target includes the Global Positioning System (GPS) latitude 
and longitude position, altitude in feet above mean sea level (MSL), ground speed in knots, 
track angle in degrees true and a time stamp for the data. Other data needed by the 
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algorithm such as acceleration, vertical speed, closing distance, etc., must be computed 
from the reported values. The reported values are updated at regular intervals depending 
on the source of the data. Ideally, the data rate will be at least once per second. However, 
as discovered during both the DFW and GVSITE flight tests, the one second traffic updates 
are the exception rather than the rule. 

When all or any specific reported values are not up to date, an estimate of the current 
value(s) must be made by projecting the last known values. This process, known as data 
smoothing, involves computations that decrease in accuracy with increasing time between 
updates, and is further complicated by different data rates for specific values and 
uncertainty in the exact time since the last update. For example, the position update might 
be at one hertz but the update rate for ground speed is two or three hertz and the exact 
update times may not be known. Because the accuracy of traffic data is so critical to 
correct conflict detection, a great deal of effort has been made to insure that traffic 
smoothing and computations of non-reported values are as accurate as possible. 

3.2.3. 1.2 Determining the Traffic Operational State 

The traffic state for each target is determined after all the data values for that target have 
been derived, computed and/or smoothed. The correct performance of RSM depends on 
how accurately this process is performed. (See definition of operational states in Section 
3.1.1.) The criteria used to detennine traffic state have been derived empirically based on 
numerous flight simulations and flight testing. The criteria for ground based traffic 
include: ground speed above or below a defined maximum taxi speed; acceleration above 
or below a takeoff acceleration threshold; on or off the runway and heading in the general 
direction of the runway. The criteria for airborne traffic include: altitude above or below 
the incursion zone altitude; vertical speed and track lined up with the runway (within angle 
tolerance). If a target’s altitude is above the zone altitude, no further testing is done for the 
target; however, its data is maintained in the zone target list and monitored on subsequent 
traffic scans in the event the target drops below the zone altitude. In some cases, the 
threshold values for the state criteria are defined as parameters in RSM configuration files 
so they can be modified for different airport/aircraft requirements. 

3.2. 3.2 Detecting Conflicts in the Ownship Zone 

When the traffic monitoring function finds a target in the ownship zone, obtains accurate 
data for the target and determines the traffic state, testing of this target for conflicts is 
performed using the operational state matrix and alert criteria for single runways (Figure 
15). It is possible to have more than one conflict occurring at the same time in ownship ’s 
incursion zone. Currently, there is a limit of two simultaneous conflicts. This limit has 
been adequate in testing, but if necessary, the limit can be increased by allocating more 
memory space for alert data. 

3.2.3.2.1 Applying Operational State Matrix & Alert Criteria for Single Runways 

A conflict is considered possible based on the combination of operational states for 
ownship and the target (see Figure 15). If a state combination results in the possibility of a 
conflict, i.e., a YES in the matrix, additional alerting criteria are tested to determine if a 
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conflict situation is in progress. The specific alerting criteria vary based on state 
combination. For example, if ownship is on a takeoff roll and a target is taxiing, the 
alerting criteria include horizontal distance closure between ownship and target. But if 
both ownship and target are in the process of taking off or landing, the alerting criteria 
include directions of movement, separation distance, and distance closure. In these cases, 
when ownship and target directions of movement are the same, it is a chase situation and is 
a conflict if distance is less than a defined minimum separation, i.e., loss of separation. 
When directions of movement are opposite, it is a head-on conflict and minimum 
separation is not applicable. The following is a more detailed description of the more 
common types of conflicts identified by the operational states matrix. 


Both ownship and target in the taxi state : 

A taxi only operation occurs when both ownship and the target are taxiing or stationary. 
This situation was not considered for incursion testing at the time of the DFW flight 
test. However, new capabilities in the current version of RSM monitor the taxi only 
operations for potential conflicts if at least one aircraft is taxiing after a landing rollout 
or aborted takeoff, or if two aircraft get too close on the runway. 


Ownship in the pre-takeoff state : 

When ownship is on the runway in position for takeoff or just starting takeoff roll, the 
ownship state is changed from taxi to pre-takeoff state. The pre -takeoff state indicates 
the “intent” to takeoff immediately. The criteria used to determine this state include 
being on the runway with the same heading as the runway and acceleration, but may 
also include takeoff mode and throttle position depending on the type of aircraft and the 
availability of flight data. 

The pre-takeoff state can only be detennined for ownship at the present time since the 
intent of other traffic cannot be known a priori. For this reason, the operational states 
matrix does not include a pre -takeoff column for targets. Traffic must be well into the 
takeoff roll as indicated by speed, acceleration, etc., before intent to takeoff is known. 
Significant improvements have been made in the advanced version of the algorithm to 
detect traffic takeoffs as soon as possible at the beginning of the takeoff roll. However, 
further improvements can only be made if additional traffic “intent” data become 
available. 

When ownship is in the pre-takeoff state, a conflict is possible for any target state. 
However, additional alerting criteria must be tested to prevent false alarms. If the target 
is taxiing or stationary, the target must be ahead of ownship in the takeoff path and not 
clear of the runway. If the test for these criteria returns true, a conflict alert (RCA) will 
be generated either before ownship starts the takeoff roll or very early in the takeoff 
roll. For example, if the target happens to be stationary equipment on the runway and 
ownship is in the pre-takeoff state, the hazard would be recognized immediately and the 
alert would be issued prior to any movement that could cause a collision. 
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Either ownship or target in a landing/takeoff state while the other is in a taxi state : 


The state conditions in this category include combinations of ownship landing/taking 
off and target taxiing/stationary or target landing/taking off and ownship 
taxiing/stationary. The landing and takeoff states include takeoff roll, climb out, 
landing approach and roll out. For any of these conditions, the primary alerting criteria 
are taxiing/stationary traffic not clear of the runway and decreasing separation between 
ownship and the target (closure). Other criteria are also applied to prevent false alarms 
depending on the combination of states. 

The criterion for separation closure is necessary to prevent false alarms by 
distinguishing non-conflicting targets located behind an aircraft on takeoff or landing. 
A positive closure rate indicates that the taxiing aircraft or vehicle is in the direct path 
of the aircraft taking off or landing. For example, if ownship is taxiing across the hold 
short line and enters the incursion zone while a target aircraft is on takeoff roll or 
landing, a conflict will be detected immediately and an alert will be generated in 
sufficient time to stop the aircraft before reaching the runway. Or, if ownship is on a 
takeoff roll and a target is crossing the runway in the takeoff path, an alert will be 
issued before ownship ’s ground speed becomes too high for a rejected takeoff. If 
ownship is on final approach, an alert will be issued with sufficient lead time, distance 
and altitude to abort the landing and go around. 

A new capability was developed after the DFW flight test for situations when ownship 
is taxiing toward a runway but is taxiing too fast to stop before the hold line or may not 
intend to stop. The algorithm computes a projected position ahead of the aircraft (a 
look-ahead point) based on the taxi speed, deceleration, stopping distance and other 
factors. If the look-ahead point enters the incursion zone of an active runway with 
traffic taking off or landing, an alert will be generated that will allow ownship to stop 
before the hold line. If ownship is already slowing down before reaching the hold line, 
the look-ahead point recedes closer to the nose of the aircraft and an alert will not be 
generated. 

Both ownship and target in the landing or takeoff state : 

The state conditions in this category include all combinations of both ownship and 
target taking off and/or landing. These situations are potential conflicts since no more 
than one landing or takeoff operation should occur at any one time on the same runway. 
A chase situation occurs when both aircraft are landing or taking off in the same 
direction, or one is landing from behind while the other is taking off. In these cases, the 
alerting criterion for minimum separation distance is used to detect loss of separation. 
If two land or takeoff operations are in opposite directions, an alert is issued regardless 
of separation distance. 


Fly-thru states : 

One other aircraft operational state is possible for ownship and traffic that is neither taxi 
nor land/takeoff. The fly-thru state occurs when the aircraft is airborne and is flying 
across the runway incursion zone below the incursion zone altitude. Note that an 
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aircraft flying in the incursion zone with the same heading as the runway would be 
interpreted as a landing or takeoff, not a fly-thru state. The fly-thru state may occur 
when rotary aircraft/helicopters fly within the airport boundary at low altitudes directly 
across runways. More often, the fly-thru state is observed when aircraft on final 
approach to a runway cross an intersecting incursion zone for another runway. Fly-thru 
states can generate incursions; however, to avoid issuing alerts that are false alarms, 
additional alerting criteria must be tested. For example, if ownship is taking off or 
landing and a target is observed inside the zone in the fly-thru state, an alert will be 
issued if alerting criteria indicate that the target is in ownship ’s takeoff or landing path 
and the distance is less than the minimum separation. In this example, a helicopter 
could be crossing the runway at a low altitude immediately in front of the departing 
aircraft. Another example is when ownship is taking off and another aircraft on 
approach to a different runway crosses ownship ’s runway zone near the end where the 
two zones intersect. In this case, an alert may not be issued if the distance between 
aircraft is greater than the minimum separation. 


3.2.3.2.2 Aging Conflict Alerts 

When a conflict alert is generated, it is possible that the conflict will appear to no longer 
exist when subsequent traffic data is received. This can happen when the traffic data are 
erratic and inconsistent, i.e., bad data is received followed by good data. In this case, an 
aural and visual alert might be issued, then terminated, then reissued several times for the 
same conflict and can be very distracting to the pilot and crew. One technique used by 
RSM to minimize this on-off alert sequence is to age or coast the conflict alert for one or 
two seconds after the conflict ends. Aging the alert has the effect that multiple alerts are 
less likely to be issued for the same conflict and only one alert will be issued unless there 
are continued problems with the data. Alert aging can also occur even when the data is 
good under some conditions, but does not apply if an alert is tenninated because either 
ownship or the target involved in the conflict is no longer inside the incursion zone or is 
above the incursion zone altitude. 


3.2.4 Component 4: Crossing Runway and Intersecting Flight Path Conflicts 

After testing for conflicts in the ownship zone, Component 4 starts the process of testing 
for conflicts in other runway incursion zones that intersect the ownship zone. The 
intersection point can be on the runway itself, i.e., a crossing runway, or at points before or 
beyond the ends of the runway, i.e., crossing flight path. Either of these situations is 
referred to in RSM as a crossing runway incursion zone or just crossing zone. The 
capability to detect conflicts in crossing zones is a major enhancement to RSM that was not 
available for the DFW flight test but has been tested extensively in the flight simulator and 
during the GVSITE flight test. The software design methodology for crossing zones is 
similar to the methodology for single runways. A major difference is that there may be 
more than one crossing zone that has to be monitored for traffic and tested for conflicts. 
Also, the operational state matrix and alerting criteria for crossing zones are significantly 
different than the matrix and criteria for single runways. Just as for single runways, the two 
main tasks are traffic monitoring to find and obtain data for traffic inside each crossing 
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zone and conflict testing in each crossing zone. Traffic monitoring for crossing zones is 
done the same way as traffic monitoring in the ownship zone described in Section 3.2.3. 1 
above. The following is a description of how conflicts are detected in crossing zones. 


3.2.4.1 Detecting Conflicts in the Crossing Zones 

When the traffic monitoring function finds a target in a crossing zone, obtains accurate data 
for the target and determines the traffic state, testing of this target for conflicts is performed 
using the operational state matrix and alerting criteria for crossing zones (Figure 16). As 
for single runway conflicts, there is a limit of two simultaneous conflicts in a crossing zone 
but this would be a very rare occurrence. In the unlikely event there is a total of more than 
two conflicts in the ownship zone and all crossing zones, conflicts are prioritized with 
ownship zone given highest priority followed by crossing zones closest to the ownship 
position. The aging of conflict alerts (Section 3.2. 3.2. 2) is also applicable for crossing zone 
conflicts. 


3.2.4.1.1 Applying Operational State Matrix & Alert Criteria for Crossing Zones 

A conflict is considered possible based on the combination of operational states for 
ownship and the target (Figure 16). If a state combination results in the possibility of a 
conflict, i.e., a YES in the matrix, additional alert criteria are tested to determine if a 
conflict situation is in progress. The alert criteria differ based on the combination of states 
in the matrix. For example, the alert criteria are different for the combinations of ownship 
takeoff roll / traffic takeoff roll and ownship land / traffic land. It also makes a difference 
where the common intersection is located, i.e., whether the runways directly cross each 
other or one runway crosses the flight path of another runway or both runway flight paths 
cross each other. The following is an explanation of the common scenarios identified by 
the operational state matrix for crossing zones. 


No conflict scenarios: 


If the target is in a taxi/stationary or fly-thru state, no conflict alert is issued. A conflict 
is considered possible only if traffic is taking off or landing and will cross the common 
intersection with ownship ’s runway. If traffic is in a taxi or fly-thru state on a crossing 
runway and enters ownship ’s runway incursion zone, this situation will be tested for 
single runway conflicts described in Section 3.2.3 above. 


Ownship taxi/fly-thru two zones: 

This situation occurs when ownship is taxiing on a runway, e.g., after a rollout or when 
the runway is used as a taxiway, and enters the crossing zone of another runway where 
traffic is landing or taking off. In this case, ownship is in two runway zones at the same 
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time. This scenario does not use alert criteria for crossing zones but uses single runway 
criteria for both zones that ownship is in. The situation also covers rare cases when 
ownship could be flying through the common intersection of two runways. This case is 
also handled as two separate single runway scenarios. 

Departure/departure scenarios: 

These scenarios involve all combinations of ownship departure states (pre -takeoff, 
takeoff roll or climb-out), and traffic departure states (takeoff roll, climb-out) when 
traffic is in a crossing zone such as crossing runway or intersecting flight path. For 
these scenarios, alerting criteria are based on ATC guidelines for intersecting runway 
separation when both the ownship aircraft and another aircraft are departing [Ref. 6, 
Para 3-9-8]. These guidelines specify that the departing aircraft does not begin takeoff 
roll until the other departing aircraft has passed the intersection or is turning to avert 
any conflict. To satisfy these guidelines, RSM issues a conflict alert as early as 
possible during ownship ’s departure so the takeoff can be easily aborted to avert any 
possibility of a collision. The ideal is to alert during ownship ’s pre-takeoff state when 
ownship is not moving or has just started the takeoff roll. This is only possible if traffic 
on the crossing runway has already its started takeoff roll or is climbing out and is not 
past the intersection. If ownship starts its takeoff roll first, the alert will occur later 
after traffic begins takeoff. If ownship starts takeoff first and the other departing 
aircraft is also equipped with RSM, that aircraft would get a conflict alert that would 
result in a rejected takeoff. 

Departure/arrival scenarios: 

These scenarios involve all combinations of ownship departure states (pre -takeoff, 
takeoff roll, climb-out) and traffic arrival states (land, rollout) when traffic is in a 
crossing zone. Alerting criteria are based on ATC guidelines for intersecting runway 
separation when the ownship aircraft is departing and another aircraft is arriving [Ref. 
6, Para 3-9-8]. These guidelines specify that the departing aircraft shall not begin its 
takeoff roll until the arriving aircraft is clear of the landing runway, has completed the 
landing roll and will hold short of the intersection, or has passed the intersection. Just 
as for departure/departure scenarios above, alerts for departure/arrival scenarios are 
issued as early as possible during ownship’s departure. 

Arrival/departure scenarios: 

These scenarios involve all combinations of ownship arrival states (land, rollout) and 
traffic departure states (takeoff roll, climb-out) when traffic is in a crossing zone. 
Alerting criteria are based on ATC guidelines for intersecting runway separation when 
the ownship aircraft is arriving and another aircraft is departing [Ref. 6, Para 3-10-4]. 
These guidelines specify that the arriving aircraft shall not cross the landing threshold 
or flight path of the departing aircraft until the departing aircraft has passed the 
intersection/flight path or is airborne and turning to avert any conflict. To satisfy these 
guidelines, RSM issues a conflict alert when ownship is far enough from the landing 
threshold or flight path intersection to take evasive action to avert a conflict (e.g., go- 
around). 
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Arrival/ar rival scenarios: 


These scenarios involve all combinations of ownship arrival states (land, rollout) and 
traffic arrival states (land, rollout) when traffic is in a crossing zone. Alerting criteria 
are based on ATC guidelines for intersecting runway separation when the ownship 
aircraft is arriving and another aircraft is arriving [Ref. 6, Para 3-10-4], These 
guidelines specify that the arriving aircraft shall not cross the landing threshold or flight 
path of the other aircraft (intersection) until the arriving aircraft is clear of the landing 
runway, has completed landing roll out and is holding short of the intersection, or has 
passed the intersection/flight path. Just as for the arrival/departure scenarios, alerts for 
arrival/arrival scenarios are issued when ownship is a sufficient distance from the 
landing threshold or flight path intersection to take evasive action to avert a conflict. 


3.2.4.1.2 Land And Hold Short Operations 

Land and hold short operations (LAHSO) are in use at many airports to control traffic on 
crossing runways. These operations are germane to conflict detection and alerting because 
the ATC guidelines do not consider a situation to be a conflict if an arriving aircraft has 
completed the landing roll out and will hold short of the intersection. LAHSO operations 
present some problems for RSM due to lack of information when these operations are in 
effect. The LAHSO instructions from the ATC controller apply to ownship’s runway, 
traffic on a crossing runway or both. If ownship is instructed to land and hold short of an 
intersection, it is not a conflict when traffic is taking off or landing on the crossing runway. 
Conversely, if traffic is instructed to land and hold short, ownship can land or takeoff 
without a conflict. However, RSM has no way of knowing when and what LAHSO 
instructions have been issued and, therefore, cannot integrate these operations. Even if the 
operations are known, other factors must be considered such as when landing roll out is 
completed and the aircraft’s ability to stop or turn off before the intersection. 

The current version of RSM considers these and other factors in the conflict alerting 
criteria. For example, an alert will not be issued if the aircraft has completed its rollout 
before reaching a certain distance from the intersection and will be able to stop with a 
nonnal deceleration for the type of aircraft. RSM currently assumes that no LAHSO 
instructions are in effect for either runway. However, future capabilities with Controller 
Pilot Data Link Communications (CPDLC), and/or enhancements to traffic data may 
provide the necessary information to consider LAHSO. 


3.2.5 Component 5: Processing Conflict Alert Data 

After conflict testing is completed for all applicable runway incursion zones (Components 
3 and 4), Component 5 processes and formats the alert data for output to RIPS software 
through RSM Main. This function involves writing the alert data to a local RSM alert data 
structure that includes a numeric value for the type of alert (RCA - see Section 2.1), a 
numeric id for other traffic involved in the conflict, the distance to the conflict in feet and 
the time in seconds to the conflict. Distance and time to the conflict are based on the 
separation from ownship to the target for single runway conflicts and the separation from 
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ownship to the intersection for crossing zone conflicts. The alert variables are based on the 
information needed for alert displays in the cockpit, but can be changed to meet future 
display requirements. If there are no conflicts, the alert data structure is cleared. Alert data 
can be written for one conflict or for two simultaneous conflicts in the same or different 
incursion zones. In the unlikely event there are more than two conflicts, any conflict in the 
ownship zone has highest priority followed by conflicts in crossing zones closest to the 
ownship position. When alert processing is completed, control is returned to RSM main 
where the alert data output function is called (see Section 3.2. 1.3). Note that the alert 
processing function in Component 5 no longer writes alert data directly to RIPS shared 
memory as it did during the DFW flight test. This output function has been encapsulated in 
RSM main so the method of inter-process communications, currently a shared memory 
interface, can be changed without affecting any of the algorithm code. 


4.0 RSM PERFORMANCE RESULTS 


The RSM algorithm was tested extensively during the GVSITE flight tests at Reno and 
Wallops in July and August 2004. Data from all flight tests were recorded by RIPS 
communications software on board the GV for playback and post analyses. Data were also 
recorded by the Synthetic Vision System (SVS) software and made available for use in the 
event RIPS recordings were missing or corrupted. The performance results are 
summarized for each of the runway incursion scenarios that were tested at Reno and 
Wallops. Seven scenarios were tested at Wallops (Figures 3-9) and four scenarios were 
tested at Reno (Figures 10 - 13). These scenarios were chosen to evaluate new capabilities 
of RSM, including alerts for crossing runway conflicts, alerts during taxi operations to 
prevent crossing the hold line when a runway is active, and alerts for conflicts with arriving 
traffic when ownship is holding for takeoff. Tables 1 and 2 list the overall perfonnance 
results for Wallops and Reno, respectively. All scenarios used the GV research aircraft as 
the ownship, a BE200 King Air general aviation aircraft as other traffic, and a NASA 
research test van as vehicle traffic. The test results for each scenario will be followed by an 
overall performance summary with lessons learned during GVSITE. 

4.1 Incursion Scenario 1 - Crossing Runway 
Ownship Departure / Traffic Departure 


During Scenario 1, the GV (ownship) was taking off while the BE200 (traffic) was 
simulating a takeoff on a crossing runway. The BE200 was required to accelerate to a 
speed of 40 to 50 knots, hold that speed as long as possible then slow down and stop before 
the intersection. The GV evaluation pilot was trained to execute a rejected takeoff (RTO) 
upon receipt of the Runway Conflict Alert (RCA). The timing conditions varied for each 
Scenario 1 test run. Sometimes the BE200 was released to start the simulated takeoff 
before the GV began its takeoff roll and at other times the GV started takeoff first. A 
runway conflict was considered to be in progress when both aircraft were in the process of 
taking off. 
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Results for Wallops (Figure 3, Table 1) : There were a total of 8 data runs for Scenario 
1 at Wallops. RSM issued RCA’s on all 8 runs. There were no late or false alerts. The 
starting takeoff position for the BE200 on the crossing runway averaged 1275 ft from 
the threshold because the beginning section of the runway was closed. When the RCA 
was issued, the average ground speed for the GV was 65 knots and the average ground 
speed for the BE200 was 18 knots. These numbers indicate that normally the GV was 
already into the takeoff roll when the BE200 started its takeoff and the takeoff state for 
the BE200 was detected very early (with speed below 20 knots and an average of 135 ft 
from start position). The RTO was executed after the RCA when the GV was an 
average of 78 knots and 4626 ft from the intersection. The conflict alert resulted in the 
RTO being executed with more than sufficient lead time and distance from the 
intersection to stop safely and avert the possibility of a collision. 

Results for Reno (Figure 10, Table 2) : There were a total of 1 1 data runs for Scenario 1 
at Reno. RSM issued RCA’s on all 1 1 runs and there were no late or false alerts. 
When the RCA was issued, the average ground speed for the GV was 49 knots, and the 
ground speed for the BE200 averaged 33 knots and 536 ft from the starting takeoff 
position. The RTO was executed after the RCA when the GV was an average of 62 
knots and 5702 ft from the intersection. There was more than sufficient lead time after 
the alert to stop the aircraft a safe distance from the intersection. 


4.2 Incursion Scenario 2 - Crossing Runway 
Ownship Departure / Traffic Arrival 

Scenario 2 involved the GV (ownship) taking off while the BE200 (traffic) was simulating 
a landing approach to a crossing runway. The BE200 was required to initiate a go-around 
at 200 ft AGL as a safeguard. The GV started its takeoff roll when the BE200 was less 
than 2 mn from the landing threshold. The GV evaluation pilot was trained to initiate an 
RTO upon receipt of the RCA. A runway conflict was considered to be in progress as soon 
as the GV started takeoff. Scenario 2 was tested only at Wallops. 

Results for Wallops (Figure 4. Table 1) : There were a total of 7 data runs for Scenario 
2. RSM issued RCA’s on all 7 runs. There were no late or false alerts. When the RCA 
was issued, the BE200 was about 1.6 mn from the landing threshold and the GV had 
just started takeoff with an average speed of 24 knots and had only moved a short 
distance, indicating that the conflict was detected very early. The RTO was initiated 
after the RCA when the GV was traveling at an average of 42 knots and was at a safe 
distance of over 5000 ft from the intersection. 


4.3 Incursion Scenario 3 - Crossing Runway 
Ownship Arrival / Traffic Departure 

During Scenario 3, the GV (ownship) was landing while the BE200 (traffic) was simulating 
a takeoff on a crossing runway. The GV evaluation pilot was trained to initiate a go-around 
upon receipt of the RCA. The timing conditions varied for each Scenario 3 test run 
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depending on when the BE200 was released to begin takeoff. The timing differed 
considerably between Wallops and Reno test runs because of differing airport geometry. 
At Wallops, the BE200 was released when the GV was on final and approximately 1.5 mn 
from the threshold. As a result, the RCA occurred while the GV was still on final approach 
and a go-around maneuver was conducted. At Reno, the BE200 was released when the GV 
was past the threshold close to touch down. The GV evaluation pilot had the option of 
aborting the landing or landing and stopping before the intersection. The latter action was 
taken in all cases since the intersection was far enough from the touch down point to safely 
decelerate and stop before the intersection. For both Wallops and Reno, a runway conflict 
was considered to be in progress as soon as the BE200 started its takeoff roll. 

Results for Wallops (Figure 5, Table 1) : Out of a total of 22 data runs for Scenario 3 at 
Wallops, RSM issued RCA’s on 21 of those runs. No RCA was issued on one run 
because the BE200 did not start the simulated takeoff and there was no conflict. There 
were no late or false alerts. Based on the average of all runs, the RCA was issued when 
the GV was at an altitude of 296 ft AGL, 1.0 mn from the threshold and 1.9 mn from 
the intersection. The go-around was initiated at an average altitude of 214 ft AGL and 
0.6 mn from the threshold. When the conflict alert was issued, the ownship was far 
enough from the landing threshold to initiate a go-around in order to avert a conflict at 
the intersection of the crossing runway. 

Results for Reno (Figure 11, Table 2) : There were a total of 19 data runs for scenario 3 
at Reno. RSM issued RCA’s on 18 of those runs. No RCA was issued on one run due 
to significant problems with the GPS receiver on the BE200 that caused erroneous 
latitude and longitude positions. There were no late or false alerts. The RCA was 
always issued as soon as the BE200 started takeoff, at an average ground speed of 13 
knots. When the RCA occurred, the GV was just seconds from touch down at an 
altitude of approximately 25 ft AGL and an average distance of 5739 ft from the 
intersection. The pilot landed the aircraft and decelerated during rollout to a speed of 
less than 40 kt at an average distance of 1441 ft from the intersection. 


4.4 Incursion Scenario 4 - Crossing Runway 
Ownship Arrival / Traffic Arrival 

Both the GV and the BE200 were on final approach to intersecting runways during 
Scenario 4. The BE200 was required to initiate a go-around at 200 ft AGL. The GV 
evaluation pilot was trained to initiate a go-around upon receipt of the RCA or the GV 
safety pilot would initiate a go-around at 200 ft AGL if no RCA was issued. This scenario 
illustrated a flight condition not included in the formal FAA definition of incursion since 
both aircraft were airborne (see Section 1.0). However, the scenario would be considered a 
runway conflict based on ATC regulations for separation of arriving aircraft on crossing 
runways. Scenario 2 was tested only at Wallops. 


Results for Wallops (Figure 6, Table 1) : There were a total of 8 data runs for Scenario 
4. RSM issued RCA’s on all 8 runs with no late or false alerts. Based on the average 
for all runs, the RCA was issued when the BE200 was 1 .2 mn from the traffic runway 
threshold at an altitude of 455 ft AGL, and the GV was 1.3 mn from the ownship 
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runway threshold at an altitude of 5 16 ft AGL. The go-around was initiated by the GV 
after the RCA at an average altitude of 470 ft AGL and 1.2 mn from the threshold. 
Thus the RCA provided adequate lead time on all Scenario 4 runs to safely abort the 
landing and avert the possibility of a collision at the intersection of traffic’s arrival 
runway. 

4.5 Incursion Scenario 5 - Single Runway 
Ownship Taxi Crossing / Traffic Departure 

During Scenario 5, the GV was cleared to taxi across a runway on which the BE200 was to 
simulate a takeoff. When the GV was a specified distance from the hold line, the BE200 
was released to start a simulated takeoff in the same manner as for scenarios 1 and 3, 
creating a potential conflict if the GV did not stop at the hold line. This scenario was 
designed to test the look-ahead capability of RSM which enables the issuance of a conflict 
alert before the aircraft reaches the hold line, if there is a high probability that the aircraft 
could not or would not stop at the hold line. Scenario 5 was similar to the taxi/departure 
scenarios tested during the DFW flight test. During that flight test, the RCA was issued 
when the ownship taxied past the hold line and there was a conflict with arriving or 
departing traffic. However, during GVSITE the RCA was issued in time to stop the aircraft 
before reaching the hold line based on the deceleration characteristics of the ownship 
aircraft and the taxi speed. The faster the taxi speed, the farther the distance the alert would 
be issued before the hold line. To avoid false alerts, an alert was not issued if the aircraft 
was already slowing down enough to stop before the hold line. 

Timing the release of the BE200 for takeoff was difficult for this scenario. If the BE200 
was released too soon, there was no conflict because the BE200 had completed its takeoff 
roll before the GV was close enough to the hold line to issue the alert. Another difficulty 
with testing this scenario was that, in some cases, the GV evaluation pilot saw the BE200 
on the runway and took evasive action by braking and slowing down, causing the RCA to 
not be issued. When the timing was appropriate and the evaluation pilot did not anticipate 
the alert, RSM issued a conflict alert in time to stop the GV before the hold line. Due to the 
timing difficulties, RCA’s were not issued on some runs for this scenario at Reno. At 
Wallops timing was less of an issue and an alert was generated on every run for this 
scenario. 

Results for Wallops (Figure 7. Table 1 : There were a total of 7 data runs for Scenario 5 
at Wallops. RSM issued RCA’s on all 7 of those runs. There were no late or false 
alerts. Based on the average of all runs, the RCA was issued when the GV was 314 ft 
from the hold line taxiing at 19 kts, and the BE200 was on takeoff roll at 36 kts and 
1700 ft from the taxiway intersection. After the RCA, the evaluation pilot started 
braking and stopped the aircraft an average distance of 1 17 ft from the hold line. The 
testing for this scenario was highly successful since the alerts were always issued in 
time to stop the aircraft before the hold line. However, it could be argued that the 
alerting distance was too far from the hold line and might generate nuisance alerts 
during actual airport operations. For this reason, the RSM alerting parameters for this 
scenario are configurable for different airports and/or ownship aircraft. The parameters 
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such as deceleration and other factors can be modified in the configuration file to vary 
the alert distance or turn off alerting (before the hold line) altogether. 

Results for Reno (Figure 12, Table 2) : There were a total of 1 1 data runs for Scenario 5 
at Reno. RSM issued RCA’s on 5 of those runs. Of the six runs that did not result in 
an alert, one was caused by erroneous position data and a bad GPS receiver on the 
BE200, as reported above for Reno scenario 3. The other five runs did not have RCA’s 
generated because of the timing issues described above. Timing was more difficult at 
Reno than at Wallops, possibly because Reno was the first flight evaluation and there 
was little experience, and because the distances were more difficult to estimate at Reno. 
In the worst cases, the BE200 was released too soon and had already finished the run 
before the GV was close enough to the hold line to get an alert. In other cases, the GV 
evaluation pilot saw the BE200 and started braking before the alert could occur. For 
these reasons, the non-alert runs are not considered missed alerts since they would be 
considered invalid or false alerts if they had been issued. For the runs in which alerts 
occurred, the RCA was issued when the GV was an average of 345 ft from the hold line 
or 515 ft from the edge of the runway, and the GV stopped 179 ft from the hold line. 
One false RCA was issued by RSM after a scenario 5 run had ended. The alert 
occurred when the GV was taxiing across the runway close behind the BE200 that was 
heading in the opposite direction. The false alert was a lesson learned that has resulted 
in changes to the alerting criteria, and the changes have been tested without further 
false alerting. 


4.6 Incursion Scenario 6 - Single Runway 
Ownship Takeoff Hold / Traffic Arrival 

During Scenario 6, the GV was holding in position for takeoff near the threshold while the 
BE200 was landing on the same runway. This scenario was only tested at Wallops. The 
BE200 was required to go-around by 200 ft AGL. The GV evaluation pilot was instructed 
to not maneuver the aircraft after receipt of the RCA. Scenario 6 was designed to test the 
capability to alert the holding aircraft as soon as possible of a conflict with traffic landing 
on the same runway. The RCA was issued when the BE200 was lined up with the runway 
on final approach to allow as much reaction time as possible for the GV on the runway. 
This scenario is an example of an incursion that occurred at Los Angeles International 
Airport (LAX) on August 19, 2004. A near collision occurred between a Southwest 
Airlines B-737 in position for takeoff and an Asiana Airlines B-747 landing on the same 
runway. The B-747 aborted landing procedures when close to the threshold and over flew 
the B-737. 

Results for Wallops (Figure 8, Table 1) : There were a total of 7 data runs for scenario 
6. RSM issued RCA’s on all 7 runs. There were no late or false alerts. Based on the 
average for all runs, the RCA was issued when the BE200 was 2. 1 mn from the runway 
threshold at an altitude of 652 ft AGL. For the LAX incursion sited above, the GV 
represents the B-737 holding in position for takeoff and the BE200 represents the B- 
747 on final. The RCA would have enabled the holding aircraft to clear the runway 
and/or contact ATC to divert the landing traffic in time to avoid this near collision. 


23 



4.7 Incursion Scenario 7 - Single Runway 
Ownship Arrival / Traffic Takeoff Hold 

Scenario 7 was just the reverse of Scenario 6 but was staged differently at Wallops and 
Reno. At Wallops, the GV was on final approach while the BE200 was holding in position 
for takeoff near the threshold of the GV arrival runway. At Reno, the GV was on final 
approach and the NASA test van was parked in the overrun area behind the threshold of the 
arrival runway. At both Wallops and Reno, the GV evaluation pilot was trained to initiate a 
go-around upon receipt of the RCA. At Wallops, this scenario was designed to test the 
capability of RSM to alert the arriving ownship aircraft of a conflict with traffic holding for 
takeoff on the arrival runway. At Reno, the scenario was designed to test alerting for an 
object on the runway overrun. The RCA was issued when the GV was approximately 1.0 
nm from the threshold, based on the desired alerting position from previous flight and 
simulation testing. 

This scenario is another example of the LAX incursion sited above, but from the 
perspective of the arriving aircraft instead of the holding aircraft. The GV represents the B- 
747 on final and the BE200 represents the B-737 holding for takeoff. The RCA would 
have allowed the arriving aircraft to abort the landing much earlier and not over fly the 
holding aircraft. Note that the conflict alerts do not occur at the same time for the holding 
aircraft and arriving aircraft. The holding aircraft receives the alert when the arriving 
aircraft is more than 2.0 nm from the threshold to allow as much time as possible to clear 
the runway and/or contact ATC. The arriving aircraft receives the alert at approximately 
1.0 nm from the threshold. The alerting distance from threshold for this scenario is 
modifiable in the RSM configuration file. 

Results for Wallops (Figure 9, Table 1) : There were a total of 23 data runs for Scenario 
7 at Wallops. RSM issued RCA’s on 22 runs. An alert was not required on one run 
because the GV initiated a go-around above 700 ft AGL and about 2.0 nm from the 
threshold. There were no missed, late or false alerts. Based on the average for all runs, 
the RCA was issued when the GV was 0.9 nm from the runway threshold at an altitude 
of 304 ft AGL. The go-around was initiated at 0.7 nm and an altitude of 252 ft AGL. 

Results for Reno (Figure 13, Table 2) : There were a total of 19 data runs for Scenario 7 
at Reno. RSM issued RCA’s on 17 runs. RCA’s were not issued on two runs due to 
erroneous position data from the BE200 caused by GPS problems as reported for 
Scenarios 3 and 5 above. There were no missed, late or false alerts. RCA’s were 
issued consistently at an average altitude of 375 ft AGL and 5827 ft from the traffic 
parked in the overrun area of the arrival runway. Go-arounds were executed in 
response to the alerts at approximately 4965 ft from the traffic position and 329 ft AGL. 
Conflict alerts for this type of incursion were proven to be very effective and capable of 
preventing collisions on the runway. 
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4.8 Performance Summary 


Wallops: During the GVSITE testing, a total of 82 RIPS test runs were completed at 
Wallops by eight evaluation pilots. RCA’s were issued by RSM on all except two runs that 
were not conflicts due to scenario timing or pilot evasive action that precluded the RCA 
from being issued. There were no missed alerts and no late or false alerts. Although there 
were some problems with the updating of traffic data, there were no traffic errors that 
caused the conflict alert to not be issued. The timeliness of RSM alerts resulted in more 
than adequate lead time for pilots to take evasive action during the flight test. For the 
ownship departure Scenarios 1 and 2, with traffic departing or arriving on a crossing 
runway, RTO’s were executed based on RSM alerts when the GV was at a ground speed of 
between 24 and 65 knots and approximately 5000 ft from the intersection. The GV was 
able to decelerate and stop long before reaching the intersection. For ownship arrival 
Scenarios 3 and 4, with traffic departing or arriving on a crossing runway, go-arounds were 
executed based on RSM alerts when the GV was generally above 300 ft AGL and 0.9 to 1.3 
nm from the threshold. For the ownship taxi Scenario 5, the GV was able to be stopped 
before the hold line based on RSM alerts of conflicts with departing traffic. For Scenarios 
6 and 7, RSM RCA’s would eliminate the type of runway incursion that occurred at LAX 
in August 2004. 

Reno: A total of 60 RIPS test runs were completed at Reno by seven evaluation pilots. 
There were no missed alerts and no late alerts. There was one false alert that resulted in 
changes to criteria to prevent future occurrences. RCA’s were not issued by RSM on 9 
data runs, four of which were caused by erroneous traffic position data for the BE200 and 
five were the result of timing issues for Scenario 5 (Taxi / Departure). Conflict alerts 
issued by RSM were timely and consistent for all scenarios. 


The GVSITE flight test results at Wallops and Reno verify that the RSM algorithm 
performed consistently and effectively in detecting all runway incursions tested with a 100 
percent success rate. Runway conflict alerts issued by RSM were always timely, providing 
maximum lead time for evasive action. Flight testing at Reno and Wallops proved that the 
RSM algorithm, executing on board an aircraft with reliable and accurate traffic data, can 
significantly reduce or eliminate the safety hazards associated with runway incursions. 


4.9 Future Research and Development 


The successful performance of RSM has been verified by flight testing and simulation 
studies. However, the research accomplished to date has been based on medium and large 
commercial aviation operations. The next step is to adapt RIPS and RSM for general 
aviation (GA) operations. This includes modifications to the RSM conflict detection and 
alerting criteria as well as changes in RIPS alerting display concepts and pilot interface. 
RIPS will also be integrated with the Synthetic Vision GA display system and will be 
evaluated in simulation and in future flight tests. RSM will continue to be tested and 
improved through RIPS research at NASA Langley Research Center to accomplish the 
ultimate goal of eliminating runway incursions as the cause of aircraft accidents for all 
types of aircraft. 
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Figure 1 - Reno Runway Incursion Zones 



Figure 2 - Wallops Runway Incursion Zones 
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RIPS WAL Scenario 1 - Runway 10 
Crossing Runway - Departure/Departure 


Ownship initiate RTO after RCA or by 80 kts 
stopping before 17-35 intersection 


Q Ownship 
Traffic (Be-200) 
Traffic (SV-RV) 
Conflict location 



RWY 4-22 CLOSED 


Traffic begins takeoff roll as ownship begins spool up, 
Accelerate to then hold 45-50 kts as long as possible, 
Conduct RTO, Stopping before 10-28 intersection 


Figure 3 - WAL Scenario 1 


RIPS WAL Scenario 2 - Runway 10 
Crossing Runway - Departure/Arrival 


Ownship begins takeoff roll when 
traffic 1.25 NM from threshold, 
Initiate RTO after RCA or by 80 kts, 
Stopping before 1 7-35 intersection 



Q Ownship 
P Traffic (Be-200) 
P Traffic (SV-RV) 
E*3 Conflict location 


Figure 4 - WAL Scenario 2 
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RIPS WAL Scenario 3 - Runway 10 
Crossing Runway - Arrival/Departure 


Ownship approach Rwy 10 at 138 kts, 

Alerts occur when ownship > 200 ft AGL, 

Ownship initiate go-around after RCA or by 200 ft AGL RWY 4-22 CLOSED 


Q Ownship 
Q Traffic (Be-200) 
Q Traffic (SV-RV) 
E9 Conflict location 


Figure 5 - WAL Scenario 3 




Traffic begins takeoff roll when ownship 1.5 NM 
from threshold, Accelerate to then hold 45-50 kts 
for as long as possible, Conduct RTO, Stopping 
before 10-28 intersection 


X 2CC n 


RIPS WAL Scenario 4 - Runway 28 
Crossing Runway - Arrival/Arrival 


Traffic approach to Rwy 22 at 125 kts, 
Initiate go-around at 200 ft AGL, 
remaining North of 10-28 






Note: Both aircraft should be approximately 2 NM from threshold at same time 

Alternate: none 

Figure 6 - WAL Scenario 4 
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RIPS WAL Scenario 5 - Runway 10 
Taxi Crossing/Departure 


Traffic begins takeoff roll when ownship -700 ft from 17-35 
Accelerate to and hold 45-50 kts, Conduct RTO, 

Begin decel when reach Rwy 10-28, 

Stopping before taxiway A 


Q Ownship 
Q Traffic (Be-200) 
Q Traffic (SV-RV) 
E3 Conflict location 



Alternate: 


Figure 7 - WAL Scenario 5 


RIPS WAL Scenario 6 - Runway 1 0 
Take-off Hold/Arrival 

Traffic to use short final, Must be at least 2.5 NM 
from threshold until ownship in position and hold, 



Figure 8 - WAL Scenario 6 


31 


RIPS WAL Scenario 7A- Runway 10 
Arrival/Take-off Hold 


Traffic in position and holding 


Ownship initiate go-around after RCA 


Q Ownship 
Q Traffic (Be-200) 
Q Traffic (SV-RV) 
E3 Conflict location 



RWY 4-22 CLOSED 


Figure 9 - WAL Scenario 7 
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RIPS RNO Scenario 1 - Runway 16R 
Crossing Runway - Departure/Departure 


Q Ownship 
ft] Traffic (Be-200) 
ft Traffic (SV-RV) 
E3 Conflict location 


FKU3 

HfV' 

4412 


BEV »*l/ \l 
4412. 


COHTOOl 

IWB — f, m < 


Ownship initiate RTO after RCA or by 80 kts, 
Stopping before runway 25 


<ffi 4*— 

jeiwist ■> 




Traffic begins takeoff roll as ownship begins 
spool up, Accelerate to then hold 45-50 kts 
as long as possible, Conduct RTO, 

Stopping before runway 16R 


Figure 10 - RNO Scenario 1 


RIPS RNO Scenario 3 - Runway 16R 
Crossing Runway - Arrival/Departure 


6 


Ownship approach Rwy 16R at 138 kts, 
Alerts occur after ownship touchdown, 
Stop before runway 25 


ft Ownship 
ft Traffic (Be-200) 
ft Traffic (SV-RV) 



E3 Conflict location 



Traffic begins takeoff roll when ownship 
10 ft from touchdown, 

Accelerate to then hold 45-50 kts as long 
as possible, Conduct RTO, 

Stopping before runway 16R 


Alternate: None that enables alerts 

after touchdown 


Figure 11 - RNO Scenario 3 
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RIPS RNO Scenario 5 - 16R 
Taxi Crossing/Departure 


Ownship taxiing on B, 

Cleared to cross runway 25, 
Ownship taxi across hold line at 
constant speed (at least 15 kts), 
Stop after RCA, Safety pilot to 
ensure stop before runway 25 


U Ownship 
P Traffic (Be-200) 
Q Traffic (SV-RV) 
1 * 1 ' Conflict location 



Traffic begins takeoff roil as ownship 
reaches taxiway November, 

Accelerate to then hold 45-50 kts, 

Conduct RTO, Stopping before runway 16R 


Figure 12 - RNO Scenario 5 


RIPS RNO Scenario 7 - Runway 16R 
Arrival/Take-off Hold 


0 


Id Ownship 
P Traffic (Be-200) 
P Traffic (SV-RV) 
(H Conflict location 


Ownship initiate go-around after RCA or by 200 ft AGL 



Traffic in position and holding, 
Per RNO request, traffic must be 
located in runway overrun area 


Air to Ground WXR 
2100 Traffic Detection 


Figure 13 - RNO Scenario 7 
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Figure 14 - RSM Algorithm High Level Flow Diagram 
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Operational States Matrix for Conflicts on Single Runways 
Test Applicable Conflict Alert Criteria: YES/NO 

"'''\"Target -> 
Ownship 

Taxi or 
Stationary 

Departure 

(Takeoff Roll, Climbout) 

Arrival 

(Approach/Land, Rollout) 

Fly-thru 

Taxi or Stationary 

YES 

YES 

YES 

NO 

Departure 

(Pre-takeoff 
Takeoff Roll 
Climbout) 

YES 

YES 

YES 

YES 

Arrival 

(Approach/Land 

Rollout) 

YES 

YES 

YES 

YES 

Fly-thru 

NO 

YES 

YES 

NO 


Conflict Alert Criteria for Single Runway Conflicts (not all inclusive): 

(1) Dist to target closing 

(2) In takeoff or landing path 

(3) Separation < criterion 

(4) Distance to threshold < criterion 

(5) Takeoff/landing in same or opposite direction 

(6) Altitude AGL < (decision ht + criterion) 

(7) Distance from threshold to target < land rollout distance for aircraft 

(8) Vertical separation < criterion 

(9) Taxi/stationary not clear of runway 

( 10 ) Taxi separation < criterion 

( 11 ) Taxi speed > criterion 


Figure 15 - Operational State Matrix for Single Runway Conflicts 
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Operational States Matrix for Conflicts in Crossing Runway Incursion Zones 
Test Applicable Conflict Alert Criteria: YES/NO 


. ^ Target -> 

^\fn Crossing Zone 

Ownship 

Taxi or 
Stationary 

Departure 

(Takeoff Roll, Climbout) 

Arrival 

(Approach/Land, Rollout) 

Fly-thru 

Taxi or Stationary 

NO 

YES 

YES 

NO 

Departure 

(Pre-takeoff, Takeoff Roll, 
Climb out) 

NO 

YES 

YES 

NO 

Arrival 

(Approach/Land, Rollout) 

NO 

YES 

YES 

NO 

Fly-thru 

NO 

YES 

YES 

NO 


Conflict Alert Criteria for Crossing Zone Conflicts (not all inclusive): 

(1) Traffic departure or arrival in crossing zone (traffic taxi/stationary and fly-thru not applicable) 

(2) Not past intersection 

(3) Airborne & not turning to avoid conflict 

(4) Distance to threshold < criterion 

(5) Distance to intersection < criterion 

(6) Dist from threshold to intersection < land rollout distance for aircraft 

(7) Conflict separation < criterion 

(8) Vertical separation < criterion 

(9) Altitude AGL < (decision ht + criterion) 

(10) Ownship taxi/fly-thru intersection of crossing zones (check single rwy criteria for both zones) 


Figure 16 - Operational State Matrix for Crossing Zone Conflicts 
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Figure 17a - Primary Flight Display Figure 17b - Electronic Moving Map 



Figure 17c - Heads Up Display (HUD) 
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Table 1 - Overall RSM Performance Results For GVSITE Flight Test At Wallops 



Scenario 1 
Dep / Dep 

Scenario 2 
Dep / Arr 

Scenario 3 
Arr / Dep 

Scenario 4 
Arr / Arr 

Scenario 5 
Taxi / Dep 

Scenario 6 
Hold / Arr 

Scenario 7 
Arr / Hold 

Total Number of Test Runs 

8 

7 

22 

8 

7 

7 

23 

Num Runs With RCA 

8 

7 

21 

8 

7 

7 

22 

Num Missed Alerts / Late Alerts 

0/0 

0/0 

0/0 

0/0 

0/0 

0/0 

0/0 

Num False Alerts 

0 

0 

0 

0 

0 

0 

0 

Num runs with no RCA due to 
errors in traffic data 

0 

0 

0 

0 

0 

0 

0 

Num runs with RCA n/a due to 
evasive action or scenario timing 

0 

0 

1 

0 

0 

0 

1 









RCA - Ownship Avg Dist from: 

Thres 750’ 
Intersec 4843’ 

Thres 349’ 
Intersec 5244’ 

Thres l.Onm 
Intersec 1.9nm 

Thres 1.3nm 
Intersec 1.4nm 

Hold line 314’ 
Runway 459’ 

na 

Thres 0.9nm 

RCA - Traffic Avg Dist from: 

Start Pos 135’ 
Intersec 1689’ 

Thres 1.6nm 
Intersec 1.8nm 

Start Pos 353’ 
Intersec 1471’ 

Thres 1.2nm 
Intersec 1.3nm 

Thres 510’ 
Taxiway 1732’ 

Thres 2.1nm 

na 

RCA - Avg ground speed (kts): 
(For Departure or Taxi) 

Ownship 65kt 
Traffic 18kt 

Ownship 24kt 

Traffic 361ct 

na 

Ownship 19kt 
Traffic 36kt 

na 

na 

RCA - Avg Radar Alt (ft AGL): 
(For Arrival) 

na 

Traffic 519’ 

Ownship 296’ 

Ownship 516’ 
Traffic 455’ 

na 

Traffic 652’ 

Ownship 304’ 

OWNSHIP EVASIVE ACTION 








STOP TAXI 

Ownship Avg Dist from: 

na 

na 

na 

na 

Hold line 117’ 
Runway 262’ 

na 

na 

RTO - Ownship Avg Dist from: 

Thres 967’ 
Intersec 4626’ 

Thres 482’ 
Intersec 5111’ 

na 

na 

na 

na 

na 

RTO - Ownship Avg grnd spd (kts) 

78kt 

42kt 

na 

na 

na 

na 

na 

TOGA - Ownship Avg Dist from: 

na 

na 

Thres 0.6nm 
Intersec 1.5nm 

Thres 1.2nm 
Intersec 1.3nm 

na 

na 

Thres 0.7nm 

TOGA - Ownship Avg Alt AGL: 

na 

na 

214’ 

470’ 

na 

na 

252’ 










Thres = Runway Threshold Intersec = Intersection Dep = Departure Arr = Arrival TOGA = go-around 
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Table 2 - Overall RSM Performance Results For GVSITE Flight Test At Reno 



Scenario 1 
Dep / Dep 

Scenario 3 
Arr / Dep 

Scenario 5 
Taxi / Dep 

Scenario 7 
Arr / Hold 

Total Number of Test Runs 

11 

19 

11 

19 

Num Runs With RCA 

11 

18 

5 

17 

Num Missed Alerts / Late Alerts 

0/0 

0/0 

0/0 

0/0 

Num False Alerts 

0 

0 

1 

0 

Num runs with no RCA due to 
errors in traffic data 

0 

1 

1 

2 

Num runs with RCA n/a due to 
evasive action or scenario timing 

0 

0 

5 

0 






RCA - Ownship Avg Dist from: 

Thres 535’ 
Intersec 5872’ 

Thres 332’ 
Intersec 5739’ 

Hold line 345’ 
Runway 515’ 

Hold Position 
5827’ 

RCA - Traffic Avg Dist from: 

Start Pos 536’ 
Intersec 2793’ 

Start Pos 89’ 
Intersec 3201’ 

Start Pos 2183’ 
Taxiway 1616’ 

na 

RCA - Avg ground speed (kts): 
(Departure or Taxi) 

Ownship 49kt 
Traffic 33kt 

Traffic 13kt 

Ownship 20kt 
Traffic 50kt 

na 

RCA: Ownship Avg Radar Alt (ft): 
(Arrival) 

na 

25’ AGL 

na 

375’ AGL 

OWNSHIP EVASIVE ACTION 

STOP TAXI 

Ownship Avg Dist from: 

na 

na 

Hold line 179’ 
Runway 349’ 

na 

ROLLOUT DECEL to < 40 KT 

Ownship Avg Dist from: 

na 

Thres 3956’ 
Intersec 1451’ 

na 

na 

RTO - Ownship Avg Dist from: 

Thres 704’ 
Intersec 5702’ 

na 

na 

na 

RTO - Ownship Avg grnd spd (kts) 

62kt 

na 

na 

na 

TOGA - Ownship Avg Dist from: 

na 

na 

na 

Hold Position 
4965’ 

TOGA - Ownship Avg Alt AGL: 

na 

na 

na 

329’ 







Thres = Rwy Threshold 


Intersec = 


ntersection 


Dep = Departure Arr = Arrival TOGA = go-around 
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